1. Field of the Invention
The present invention relates to computer malware prevention systems and software. More specifically, it relates to improving behavior monitoring methods for detecting malware on computing devices.
2. Description of the Related Art
Behavior monitoring is a methodology in the field of malware detection that does not require recognizing malware “signatures” or patterns. Nor does it require searching files for code or content that may be part of a virus or other type of malware. In contrast to these conventional signature-based malware defenses, behavior monitoring observes activities of all or most processes that executes on a computing device in real-time and searches for malicious or unusual activity or behavior to determine whether malware is present. Determining whether certain activity is malicious or suspicious typically requires examining all the processes that occur on the device. That is, generally everything that happens on the device is examined and if any of the activity looks suspicious, the code (i.e., process) causing the activity is analyzed and may be reported as malware. However, if a process is on a list of exceptions (so-called “white list”) then the process is presumed to be safe will not be flagged as potential malware.
An important issue with this type of behavior monitoring is CPU performance on the device, such as a PC. Some applications, especially in the operating system, such as file I/Os, generate hundreds of processes resulting in a large volume of activity. Behavior monitors check the activities generated by these processes one by one, and check to see if they are potentially malicious. This results in very high CPU usage. The exception list is intended to mitigate this problem. Any activity that is generated by a process that is on the exception list is skipped by the behavior monitor to reduce CPU usage. However, updating the exception list requires both human, computational, and network resources. Current solutions for updating an exception list may be characterized as passive and are prone to error. Some of the problems that arise include:
1) enumerating all processes or applications that have good reputations is infeasible;
2) it is a burden to service provider “support teams” to identify which processes or application generate large volumes of intense activities and then build new patterns based on these activities to include in the exception list (the “service provider” being a company that provides behavior monitoring software to the public); and
3) customers have to wait for the most recently updated exception list in order to solve current CPU and other performance issues (e.g., a support team sends samples of “safe” processes to a pattern team; the pattern team prepares and releases the official exception list of processes to all clients).